The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Modern software applications come in various forms including cloud native applications which divide the totality of the application into several microservices that are executed in logical containers. The microservices are separate self-contained portions of an application which are configured to perform a specific service. For example, a purchasing application may include a microservice which is used to add an item to a cart, a microservice which is used to remove items from a cart, and a microservice which facilitates purchase of items in the cart.
Microservices may be implemented as stateless application components. As the microservice comprises software code which, when executed, performs a single task, the microservices do not store the state of their individual tasks. For workflows that include a plurality of microservices, state machines are used to identify the state of the overall workflow. A state machine is a separate microservice which interacts with the other microservices to determine whether the tasks have initiated, completed, or failed. The state machine stores the state of the overall workflow, indicating which tasks have been performed and which tasks have yet to be performed.
As an example, a workflow for establishing a connection with a modem may include steps of establishing an internet protocol (IP) address and registering with a cable modem termination service (CMTS). Separate microservices may be called to perform each of these steps with a state machine tracking performance of the steps and storing the outcomes.
When an application fails at a particular step, a computer system may perform a rollback operation to reset the application to a prior stored state. With the use of microservices which perform a single task and do not store their states, a rollback may include releasing memory or other resources which have been allocated during transactions. For instance, if a microservice procured an IP address prior to failure, a rollback may include disassociating the IP address with the computer system.
In a microservice based architecture, it is sometimes detrimental to perform a full rollback in response to receiving an exception. For instance, some resources may be time consuming and/or computationally expensive to allocate. Where a failure occurs further in the workflow than the allocation of the resource, a full rollback would require the system to reallocate the resource while a partial rollback could preserve the resource by resetting the workflow to a state after allocation of the resource but prior to the exception.
While a partial rollback would be more beneficial for the computing system, it can be difficult to determine when a partial rollback should be performed. As the applications are stateless, merely receiving the exception from the application would be insufficient to determine which rollbacks will preserve the allocated resources while properly handling the received exception. Furthermore, errors can be introduced in microservices or rollback programming when many different rollback processes are defined at different points of an executable workflow.
Thus, there is a need for a system which tracks performance of microservices and generates a display which depicts the tasks affected by performance of each rollback and the locations of each exception.